第11回までの見える化は，現行システムの「静的」な側面を対象にしてきた。しかし障害が発生したときの調査では，稼働中のシステムを対象とする「動的」な側面も見える化しなければならない。しかも，アプリケーションだけでなく，ミドルウエアやOS，サーバー，ストレージなど稼働しているあらゆるシステムの構成要素を対象とする必要がある。この“動いている膨大なシステム”をどう見える化するかが，障害調査の最大の難しさだ。
本番を見える化するソフトを開発
障害発生時に，さまざまな現場にトラブル・シュータとして参加しているエスエムジーの山崎正憲氏（システムズコンサルティングディヴィジョン テクニカル コンサルタント）は「ソースコードを眺めていても，障害の原因は特定できない。稼働中にのみ収集できる情報を参照する必要がある」と指摘する。具体的には，メソッドの引数や戻り値の内容，処理時間やCPU時間などが稼働中にのみ見える化できる情報という。ただし，テスト環境で調査をしても「本番と100％同じ環境ではない以上，結果をそのまま信用するのは危険」と山崎氏は説明する。
そこで山崎氏らは，本番稼働の現行システムから情報を吸い上げて見える化するソフトを自作した（図1）。具体的には，Javaアプリケーションを対象としたクラス図とシーケンス図を自動生成するものだ。
その流れは次の通り。まず稼働中のサーバーに，ログ出力用の自作エージェントを適用する。このエージェントはサーバー上の対象アプリケーションとは独立して動作するので，元のアプリケーションに組み込まなくてもログ出力が可能である。
次に，収集したログをモデル作成用ソフトで読み込み，クラス図とシーケンス図を自動生成する。このクラス図とシーケンス図から，性能に問題があるクラスのメソッドなどを特定する。
重要なのは，動いているシステムから動的なモデルを生成している点だ。ソースコードから静的なモデルを生成するツールとは位置付けが異なる。動的なクラス図では，稼働中のオブジェクトを対象とし，未使用のコードを対象としない。つまり動作中のコードのみのクラス図となる。事前に処理時間のしきい値を設定すれば，それを超えたメソッドを反転表示できる。
一方，シーケンス図では，実際の時間軸に沿った処理の流れを確認できる。横に延びた間隔が長い処理が，時間を要している個所だ。シーケンス図でもクラス図と同様に，しきい値を超えた個所を反転表示できる。
「開発で苦労したのは，エージェントをサーバー上で動作させると，CPU使用率が50％近く上がること」（山崎氏）だった。原因はログのディスク書き込み時のオーバーヘッド。そこで山崎氏らは，ログを一度に出力せずにトランザクション単位に分割して出力させるなど，さまざまな工夫を凝らした。これにより，オーバーヘッドはほぼ無くなったという。
